home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pppext-isdn-03.txt < prev    next >
Text File  |  1993-10-14  |  16KB  |  552 lines
  1.  
  2.  
  3. Network Working Group                                        W A Simpson
  4. Internet Draft                                                Daydreamer
  5. expires in six months                                       October 1993
  6.  
  7.  
  8.                              PPP over ISDN
  9.                      draft-ietf-pppext-isdn-03.txt
  10.  
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This document is the product of the Point-to-Point Protocol Working
  16.    Group of the Internet Engineering Task Force (IETF).  Comments should
  17.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  18.  
  19.    Distribution of this memo is unlimited.
  20.  
  21.    This document is an Internet Draft.  Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups.  Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  28.    other documents at any time.  It is not appropriate to use Internet
  29.    Drafts as reference material or to cite them other than as a
  30.    ``working draft'' or ``work in progress.''
  31.  
  32.    Please check the 1id-abstracts.txt listing contained in the
  33.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  34.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  35.    current status of any Internet Draft.
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Simpson                  expires in six months                  [Page i]
  55. DRAFT                        PPP over ISDN                  October 1993
  56.  
  57.  
  58. Abstract
  59.  
  60.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  61.    transporting multi-protocol datagrams over point-to-point links.
  62.  
  63.    This document describes the use of PPP over Integrated Services
  64.    Digital Network (ISDN) switched circuits.
  65.  
  66.  
  67. Applicability
  68.  
  69.    This specification is intended for those implementations which desire
  70.    to use the PPP encapsulation over ISDN point-to-point links.  PPP is
  71.    not designed for multi-point or multi-access environments.
  72.  
  73.    "It is clear that there is never likely to be a single, monolithic,
  74.    worldwide ISDN." [7] The goal of this document is to describe a few
  75.    common implementations, chosen from the current wide variety of
  76.    alternatives, in an effort to promote interoperability.
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Simpson                  expires in six months                 [Page ii]
  110. DRAFT                        PPP over ISDN                  October 1993
  111.  
  112.  
  113. 1.  Introduction
  114.  
  115.    PPP was designed as a standard method of communicating over point-
  116.    to-point links.  Initial deployment has been over short local lines,
  117.    leased lines, and plain-old-telephone-service (POTS) using modems.
  118.    As new packet services and higher speed lines are introduced, PPP is
  119.    easily deployed in these environments as well.
  120.  
  121.    This specification is primarily concerned with the use of the PPP
  122.    encapsulation over ISDN links.  Since the ISDN B-channel is by
  123.    definition a point-to-point circuit, PPP is well suited to use over
  124.    these links.
  125.  
  126.    The ISDN Primary Rate Interface (PRI) may support many concurrent B-
  127.    channel links.  The PPP LCP and NCP mechanisms are particularly
  128.    useful in this situation in reducing or eliminating hand
  129.    configuration, and facilitating ease of communication between diverse
  130.    implementations.
  131.  
  132.    The ISDN D-channel can also be used for sending PPP packets when
  133.    suitably framed, but is limited in bandwidth and often restricts
  134.    communication links to a local switch.
  135.  
  136.    The terminology of ISDN can be confusing.  Here is a simple graphical
  137.    representation of the points used in subsequent descriptions:
  138.  
  139.                    +-------+     +-------+     +-------+
  140.                R   |       |  S  |       |  T  |       |   U
  141.                +---+  TA   +--+--+  NT2  +--+--+  NT1  +---+
  142.                    |       |     |       |     |       |
  143.                    +-------+     +-------+     +-------+
  144.  
  145.    These elements are frequently combined into a single device.
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Simpson                  expires in six months                  [Page 1]
  165. DRAFT                        PPP over ISDN                  October 1993
  166.  
  167.  
  168. 2.  Physical Layer Requirements
  169.  
  170.    PPP treats ISDN channels as bit or octet oriented synchronous links.
  171.    These links MUST be full-duplex, but MAY be either dedicated or
  172.    circuit-switched.
  173.  
  174.    Interface Format
  175.  
  176.       PPP presents an octet interface to the physical layer.  There is
  177.       no provision for sub-octets to be supplied or accepted.
  178.  
  179.       The octet stream is applied primarily at the R or T reference
  180.       points.
  181.  
  182.    Transmission Rate
  183.  
  184.       PPP does not impose any restrictions regarding transmission rate,
  185.       other than that of the particular ISDN channel interface.
  186.  
  187.    Control Signals
  188.  
  189.       PPP does not require the use of control signals.  When available,
  190.       using such signals can allow greater functionality and
  191.       performance.  Implications are discussed in [2].
  192.  
  193.       Control signals MAY be required by some of the framing techniques
  194.       described, and is outside the scope of this specification.
  195.  
  196.    Encoding
  197.  
  198.       The definition of various encodings and scrambling is the
  199.       responsibility of the DTE/DCE equipment in use, and is outside the
  200.       scope of this specification.
  201.  
  202.       While PPP will operate without regard to the underlying
  203.       representation of the bit stream, lack of standards for
  204.       transmission will hinder interoperability as surely as lack of
  205.       data link standards.  The D-channel LAPD interface requires NRZ
  206.       encoding at the T reference point.  Therefore, as a default, it is
  207.       recommended that NRZ be used over the B-channel interface at the T
  208.       reference point.  This will allow frames to be easily exchanged
  209.       between the B and D channels.
  210.  
  211.       When configuration of the encoding is allowed, NRZI is recommended
  212.       as an alternative in order to ensure a minimum ones density where
  213.       required over the clear B-channel, with caveats regarding FCS [2].
  214.  
  215.       Historically, some implementations have used Inverted NRZ (merely
  216.  
  217.  
  218.  
  219. Simpson                  expires in six months                  [Page 2]
  220. DRAFT                        PPP over ISDN                  October 1993
  221.  
  222.  
  223.       switching the sense of mark and space), in order to ensure a
  224.       minimum ones density with bit-synchronous HDLC.  The use of
  225.       Inverted NRZ is deprecated.
  226.  
  227.       Automatic Detection
  228.  
  229.          Implementations which desire to interoperate with multiple
  230.          encodings MAY choose to detect those encodings automatically.
  231.          Automatic encoding detection is particularly important for
  232.          Primary Rate Interfaces, to avoid extensive pre-configuration.
  233.          Only simple encodings are currently distinguished.
  234.  
  235.          The only reliable method of detection available is to switch
  236.          modes between the supported encodings.  Transmission of the LCP
  237.          Configure-Request SHOULD be tried twice for each mode before
  238.          switching in rotation.  This ensures that sufficient time is
  239.          available for a response to arrive from the peer.
  240.  
  241.          Max-Configure MUST be set such that the cumulative attempts
  242.          result in no more than 59 seconds of time before disconnect.
  243.          It is preferable that the usual limit of 30 seconds be
  244.          observed.
  245.  
  246.       Prior Configuration
  247.  
  248.          By prior configuration, PPP MAY also be used with other
  249.          encodings.  Because of difficulty distinguishing them, it is
  250.          not recommended that these encodings be automatically detected.
  251.  
  252.          Terminal adapters conforming to V.120 [6] can be used as a
  253.          simple interface to workstations.  Asynchronous HDLC framing
  254.          [2] is accepted at the R reference point.  The terminal adapter
  255.          provides async-sync conversion.  Multiple B-channels can be
  256.          used in parallel.  Unfortunately, V.120 has a framing mode of
  257.          its own for rate adaptation, which is difficult to distinguish
  258.          from Frame Relay, and which can confuse in-band frame
  259.          detection.  V.120 is not interoperable with bit-synchronous
  260.          links, since V.120 does not provide octet-stuffing to bit-
  261.          stuffing conversion.  Therefore, V.120 is deprecated in favor
  262.          of more modern standards, such as "PPP in Frame Relay" [4].
  263.  
  264.          The "Bandwidth On Demand Interoperability Group" has defined a
  265.          proposal called BONDING.  Multiple B-channels can be used in
  266.          parallel.  BONDING has an initialization period of its own,
  267.          which might conflict with the simple detection technique
  268.          described above, and requires extensive individual
  269.          configuration in some current implementations when multiple B-
  270.          channels are involved.  It is recommended that the PPP
  271.  
  272.  
  273.  
  274. Simpson                  expires in six months                  [Page 3]
  275. DRAFT                        PPP over ISDN                  October 1993
  276.  
  277.  
  278.          multilink procedure [5] be used instead of BONDING.
  279.  
  280.  
  281. 3.  Framing
  282.  
  283.    For B-channels, in the absence of prior configuration, the
  284.    implementation MUST first use bit-synchronous HDLC [2], as opposed to
  285.    other framings, for initial link establishment.  This assumes that
  286.    circuit-switched communications are generally [host | router] to
  287.    [host | router].
  288.  
  289.    By prior configuration, octet-synchronous HDLC [2] is recommended
  290.    where the network termination equipment interfaces directly to the T
  291.    reference point, and octet boundaries are available at the time of
  292.    framing.  Such equipment is likely to be highly integrated, and the
  293.    elimination of bit-synchronous hardware can reduce the part count,
  294.    resulting in lower cost interfaces and simpler configuration.
  295.    Octet-synchronous HDLC MUST be used with NRZ bit encoding.
  296.  
  297.    For D-channels, by default no data service is expected.  By prior
  298.    configuration, "PPP in X.25" [3] or "PPP in Frame Relay" [4] framing
  299.    MAY be used.
  300.  
  301.    Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally
  302.    distinguishable, multiple methods of framing SHOULD NOT be used
  303.    concurrently on the same ISDN channel.  There is no requirement that
  304.    PPP recognize alternative framing techniques, or switch between
  305.    framing techniques without specific configuration.
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329. Simpson                  expires in six months                  [Page 4]
  330. DRAFT                        PPP over ISDN                  October 1993
  331.  
  332.  
  333. 4.  Out-of-Band signaling
  334.  
  335.    Experience has shown that the LLC Information Element is not reliably
  336.    transmitted end to end.  The deployment of compatible switches is too
  337.    limited, and the subscription policies of the providers are too
  338.    diverse.  Therefore, transmission of the LLC-IE SHOULD NOT be relied
  339.    upon for framing or encoding determination.
  340.  
  341.    No LLC-IE values which pertain to PPP have been assigned.  Any other
  342.    values which are received are not valid for PPP links, and can be
  343.    ignored for PPP service.
  344.  
  345.    As an alternative administrative measure, multiple directory numbers
  346.    can point to the same physical access facility, by binding particular
  347.    services to each directory number.  The called party identifier has
  348.    proven to be reliably provided by the local switch.
  349.  
  350.    When a called party identifier is used, or when a future LLC-IE value
  351.    is assigned to PPP and the PPP value is received, if the LCP has not
  352.    had the administrative Open event, the call MUST be rejected.
  353.    Receivers MUST NOT accept an incoming call, only to close the circuit
  354.    or ignore packets from the circuit.
  355.  
  356.  
  357. 5.  Configuration Details
  358.  
  359.    The LCP recommended sync configuration options apply to ISDN links.
  360.  
  361.    The standard LCP sync configuration defaults apply to ISDN links.
  362.  
  363.    The typical network feeding the link is likely to have a MRU of
  364.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  365.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  366.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  367.    negotiated.
  368.  
  369.    Instead of a constant value for the Restart timer, the exponential
  370.    backoff method is recommended.  The Restart Timer SHOULD be 250
  371.    milliseconds for the initial value, and 3 seconds for the final
  372.    value.
  373.  
  374.    Implementations that include persistent dialing features, such as
  375.    "demand dialing" or "redialing", SHOULD use mechanisms to limit their
  376.    persistence.  Examples of such mechanisms include exponential
  377.    backoff, and discarding packet queues after failure to complete link
  378.    establishment.  In some implementations, discarding the transmit
  379.    queue can temporarily remove the stimulus to retry the connection.
  380.  
  381.  
  382.  
  383.  
  384. Simpson                  expires in six months                  [Page 5]
  385. DRAFT                        PPP over ISDN                  October 1993
  386.  
  387.  
  388. Security Considerations
  389.  
  390.    Security issues are not discussed in this memo.
  391.  
  392.  
  393. References
  394.  
  395.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
  396.          progress.
  397.  
  398.    [2]   Simpson, W.A., "PPP in HDLC Framing", work in progress.
  399.  
  400.    [3]   Simpson, W.A., "PPP in X.25", work in progress.
  401.  
  402.    [4]   Simpson, W.A., "PPP in Frame Relay", work in progress.
  403.  
  404.    [5]   Sklower, K., "PPP MultiLink Procedure", work in progress.
  405.  
  406.    [6]   CCITT, "Recommendation V.120: Data Communications over the
  407.          Telephone Network", Blue Book, ITU 1988
  408.  
  409.    [7]   Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan,
  410.          1992.
  411.  
  412.  
  413. Acknowledgments
  414.  
  415.    This design was inspired by the paper "Parameter Negotiation for the
  416.    Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
  417.    University of California, Berkeley, 1992, unpublished.
  418.  
  419.    Other details were gleaned from "Determination of Encapsulation of
  420.    Multi-protocol Datagrams in Circuit-switched Environments", Keith
  421.    Sklower, University of California, Berkeley, IETF IPLPDN WG draft,
  422.    July 1993.  That paper credits previous work "A Subnetwork Control
  423.    Protocol for ISDN Circuit-Switching", Leifer, D., Sheldon, S. and
  424.    Gorsline, B.; IETF IPLPDN WG draft, March 1991; and "A Negotiation
  425.    Protocol for Multiple Link-Protocol over ISDN Circuit-Switching",
  426.    Muramaki, K. and Sugawara, T.; IETF IPLPDN WG draft, May 1992.
  427.  
  428.    Thanks to Oliver Korfmacher (NetCS) for European considerations, Dory
  429.    Leifer (University of Michigan) for technical details and called
  430.    party signalling, and Vernon Schryver (Silicon Graphics) regarding
  431.    handling of link misconfiguration and timeouts.
  432.  
  433.    Special thanks to Morning Star Technologies for providing computing
  434.    resources and network access support for writing this specification.
  435.  
  436.  
  437.  
  438.  
  439. Simpson                  expires in six months                  [Page 6]
  440. DRAFT                        PPP over ISDN                  October 1993
  441.  
  442.  
  443. Chair's Address
  444.  
  445.    The working group can be contacted via the current chair:
  446.  
  447.       Fred Baker
  448.       Advanced Computer Communications
  449.       315 Bollay Drive
  450.       Santa Barbara, California  93117
  451.  
  452.       EMail: fbaker@acc.com
  453.  
  454.  
  455. Author's Address
  456.  
  457.    Questions about this memo can also be directed to:
  458.  
  459.       William Allen Simpson
  460.       Daydreamer
  461.       Computer Systems Consulting Services
  462.       1384 Fontaine
  463.       Madison Heights, Michigan  48071
  464.  
  465.       EMail: Bill.Simpson@um.cc.umich.edu
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494. Simpson                  expires in six months                  [Page 7]
  495. DRAFT                        PPP over ISDN                  October 1993
  496.  
  497.  
  498.                            Table of Contents
  499.  
  500.  
  501.      1.     Introduction ..........................................    1
  502.  
  503.      2.     Physical Layer Requirements ...........................    2
  504.  
  505.      3.     Framing ...............................................    4
  506.  
  507.      4.     Out-of-Band signaling .................................    5
  508.  
  509.      5.     Configuration Details .................................    5
  510.  
  511.      SECURITY CONSIDERATIONS ......................................    6
  512.  
  513.      REFERENCES ...................................................    6
  514.  
  515.      ACKNOWLEDGEMENTS .............................................    6
  516.  
  517.      CHAIR'S ADDRESS ..............................................    7
  518.  
  519.      AUTHOR'S ADDRESS .............................................    7
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551. Bill.Simpson@um.cc.umich.edu
  552.